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The  model  formulation,  development  process,  and  experimental  validation  of  a  new  vehicle  powertrain 
simulator  called  LFM  (Light,  Fast,  and  Modifiable)  are  presented.  The  existing  powertrain  simulators  were 
reviewed  and  it  was  concluded  that  there  is  a  need  for  a  new,  easily  modifiable  simulation  platform  that 
will  be  flexible  and  sufficiently  robust  to  address  a  variety  of  hybrid  vehicle  platforms.  First,  the  structure 
and  operating  principle  of  the  LFM  simulator  are  presented,  followed  by  a  discussion  of  the  subsystems  and 
input/output  parameters.  Finally,  a  validation  exercise  is  presented  in  which  the  simulator’s  inputs  were 
specified  to  represent  the  University  of  Delaware’s  fuel  cell  hybrid  transit  vehicle  and  “driven”  using  an 
actual  drive  cycle  acquired  from  it.  Good  agreement  between  the  output  of  the  simulator  and  the  physical 
data  acquired  by  the  vehicle’s  on-board  sensors  indicates  that  the  simulator  constitutes  a  powerful  and 
reliable  design  tool. 

©  2008  Elsevier  B.V.  All  rights  reserved. 


1.  Introduction 

With  the  introduction  of  hybrid  vehicle  technology,  the  rela¬ 
tively  simple  process  of  system  level  vehicle  powertrain  design 
has  become  more  complex  resulting  in  escalating  research  and 
development  costs.  To  contain  these  costs,  there  is  a  critical  need 
to  develop  and  validate  vehicle  simulators  which  can  predict  the 
performance  of  the  vehicle  propulsion  system  under  a  variety  of 
driving  conditions  by  accurately  modeling  every  on-board  subsys¬ 
tem.  Once  the  simulation  tool  is  validated  against  actual  vehicle 
data,  it  can  be  used  to  reliably  simulate  and  optimize  new  and 
more  advanced  vehicle  designs.  Simulation  tools  are  useful  for  the 
design  and  performance  optimization  of  vehicles  containing  mul¬ 
tiple  power  sources  and  drive  systems.  This  need  has  stimulated 
the  development  of  numerous  simulation  tools  including  PSAT  [2], 
V-ELPH  [3],  ADVISOR  [4],  and  others  [1,5-7]. 

Each  of  these  existing  simulation  systems  can  simulate  the 
entire  vehicle  powertrain.  Typically,  the  simulation  model  is  highly 
advanced,  and  requires  the  input  of  a  large  number  of  vehicle 
parameters.  However,  these  models  typically  embody  a  complex 
design  and  structure  that  does  not  permit  rapid  and  relatively  sim¬ 
ple  modifications  to  the  fundamental  vehicle  design  as  would  be 
required,  for  example,  to  conduct  a  parametric  study  that  explores 
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the  influence  of  various  input  parameters  on  the  vehicle  perfor¬ 
mance.  Therefore,  a  new  simulation  tool  was  developed  in  this 
study  for  the  express  purpose  of  providing  a  flexible,  easily  modifi¬ 
able  structure  such  that  changes  to  the  fundamental  vehicle  design 
could  be  easily  implemented  without  compromising  model  accu¬ 
racy  or  computational  performance. 

The  tool  developed  for  this  purpose  is  called  LFM  (Light,  Fast, 
and  Modifiable),  initiated  originally  by  the  Electric  Power  Research 
Institute  (EPRI).  As  its  name  suggests,  this  tool  is  specifically 
designed  for  ease  of  modification  and  rapid  execution.  Hence  this 
tool  is  well  suited  for  optimizing  the  design  of  a  hybrid  vehicle  pow¬ 
ertrain  by  a  process  in  which  the  simulation  is  executed  rapidly  and 
repeatedly  with  the  system  parameters  being  varied  incrementally 
over  a  chosen  range  without  user  interaction,  and  the  simulation 
outputs  stored  for  subsequent  analysis. 

For  this  paper,  the  LFM  simulation  parameters  were  tailored 
specifically  to  match  the  University  of  Delaware’s  fuel  cell  electric 
hybrid  bus.  The  simulator  was  exercised  using  actual  drive  cycles 
obtained  from  the  vehicle’s  GPS  system,  and  the  simulation  was  val¬ 
idated  by  comparing  its  outputs  with  data  acquired  by  the  vehicle’s 
various  on-board  sensors. 

2.  Model  design 

The  operating  environment  for  LFM  is  MATLAB/Simulink  [8,9]. 
MATLAB  is  a  programming  environment,  developed  by  The  Math- 
Works,  designed  for  rapid  numerical  code  development.  Simulink 
is  an  add-on  package  for  MATLAB  that  greatly  simplifies  the  system 
modeling  process  through  a  graphical  programming  interface. 
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Fig.  1.  LFM  schematic. 


The  basic  structure  of  LFM  is  a  drive  cycle-based,  forward-facing 
model.  Drive  cycle-based  means  that  the  simulation  is  “driven” 
entirely  by  an  input  drive  cycle.  At  each  time  step,  the  simulator 
compares  the  desired  speed  from  the  drive  cycle  with  the  current 
speed  of  the  vehicle,  and  calculates  driving  commands  to  minimize 
their  difference.  The  Simulink  model  itself  is  constructed  from  sub¬ 
systems  that  are  linked  using  electrical,  mechanical,  and  control 
signal  links.  Fig.  1  shows  the  basic  layout  of  the  LFM  simulator  for 
the  current  case  study. 

2.1.  Structure 

The  following  sections  will  elaborate,  in  some  detail,  the  func¬ 
tion  of  each  of  the  subsystems  that  constitute  the  overall  LFM 
model. 

2.1.1.  Fuel  cell  subsystem 

The  fuel  cell  subsystem  receives  a  DC  current  request  from  the 
power  converter  downstream.  The  fuel  cell  system  uses  this  cur¬ 
rent  request  to  determine  the  corresponding  voltage  output  from 
the  stack  using  a  simple  lookup  table  in  the  fuel  cell  data  spread¬ 
sheet.  This  look-up  table  is  created  from  actual  performance  data 
logged  from  the  fuel  cell  stack  (polarization  curve)  in  the  vehicle 
during  operation  and  contains  voltage  values  indexed  by  current. 
The  other  major  calculation  within  the  fuel  cell  subsystem  is  fuel 
usage  which  is  obtained  from  another  lookup  table  that  lists  the 
hydrogen  consumption  of  the  stack  for  a  given  current.  Fuel  cell 
balance-of-plant  (BOP)  loads  are  calculated  by  the  accessory  sub¬ 
system  (Section  2.1.5)  based  on  the  power  request.  Fig.  2  shows  a 
schematic  of  the  fuel  cell  subsystem. 

2.1.2.  Hybrid  controller 

The  hybrid  controller  is  responsible  for  determining  the  elec¬ 
tric  power  needed  from  the  fuel  cell  system.  This  subsystem  takes 
inputs  from  the  batteries,  the  fuel  cell,  and  the  load  combiner  and 
determines  the  power  needed  based  on  a  control  algorithm.  This 
algorithm  can  be  easily  modified  so  that  new  control  strategies  can 
be  rapidly  implemented  and  evaluated.  Fig.  3  shows  a  schematic  of 
the  hybrid  controller. 


2.1.3.  Battery 

The  battery  subsystem  (Fig.  4)  is  responsible  for  calculating 
state-of-charge  (SOC),  internal  resistance,  voltage,  and  current  and 
voltage  limits.  The  SOC  is  calculated  by  integrating  the  current  from 
the  battery  pack  with  respect  to  time,  and  then  subtracting  this 
from  the  nominal  charge  capacity  of  the  batteries.  For  example,  if 
the  batteries  nominally  hold  100  Ah,  and  the  vehicle  draws  20  A  for 
1  h,  the  SOC  will  be  80%. 

Using  the  calculated  value  for  SOC,  the  battery  subsystem  refers 
to  a  lookup  table  to  determine  open  circuit  voltage  and  internal 
resistance.  These  data  are  typically  provided  by  the  battery  manu¬ 
facturer.  For  this  particular  study,  the  data  were  provided  by  Ebus, 
Inc.,  the  manufacturer  of  the  vehicle.  Using  those  values,  the  avail¬ 
able  battery  voltage  is  calculated  by  subtracting  voltage  loss  from 
the  open-circuit  voltage,  or  Vavailable  =  V0c  -  IB  where  V0c  is  the 
open-circuit  voltage  of  the  battery  pack,  I  is  the  current,  and  R  is 
the  total  internal  resistance  of  the  string.  This  is  a  standard  internal 
resistance  model  of  a  battery  pack  that  was  validated  by  Johnson 
[10].  Also,  current  and  voltage  limits  are  placed  on  the  output  as 
specified  by  the  component  configuration  information  in  the  bat¬ 
tery  spreadsheet.  These  data  are  also  typically  provided  by  the 
battery  manufacturer.  For  example,  manufacturers  will  typically 
specify  maximum  charge  and  discharge  currents.  This  subsystem 
implements  these  extrema. 

2.1.4.  Load  combiner 

The  load  combiner  subsystem  is  responsible  for  distributing  the 
downstream  load  (traction  system  and  accessories)  among  the  dif¬ 
ferent  power  sources.  For  this  particular  model,  the  basic  strategy 
is  to  take  any  transient  load  needed  by  the  motor,  and  accessories, 
directly  from  the  batteries  while  the  fuel  cell  system  simply  delivers 
the  power  requested  by  the  hybrid  controller.  This  subsystem  is  also 
responsible  for  scaling  the  power  request  from  the  hybrid  controller 
by  the  boost  converter  efficiency  and  battery  voltage  yielding  the 
current  needed  from  the  fuel  cell  stack.  In  this  manner,  the  power 
delivered  by  the  fuel  cell  system  is  equal  to  the  power  request  from 
the  controller  (provided  the  request  is  greater  than  zero  and  less 
that  the  maximum  fuel  cell  power).  The  fuel  cell  system  power 
request  is  limited  in  the  controller,  so  the  request  will  never  exceed 
the  maximum  output  power.  Fig.  5  schematically  shows  how  the 
load  combiner  distributes  the  downstream  load  between  the  bat¬ 
tery  and  the  fuel  cell. 


Fig.  2.  Fuel  cell  subsystem. 


Fig.  4.  Battery  subsystem. 
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each  of  the  non-traction-related  electric  loads.  These  include:  bat¬ 
tery  chiller,  HVAC,  air  compressor,  power  steering,  and  fuel  cell 
balance-of-plant.  As  shown  in  Fig.  6,  at  the  top  is  the  battery  chiller 
whose  power  requirement  can  vary  depending  on  the  temperature 
of  the  batteries.  Since  this  LFM  model  does  not  perform  thermal 
modeling  of  the  batteries,  this  quantity  is  taken  as  a  constant  load 
accounting  for  the  duty  cycle  of  the  compressor.  Below  that  is  the 
FIVAC  system  which  can  be  toggled  on  or  off  by  the  configuration 
parameters  that  are  loaded  before  the  simulation  begins.  This  tog¬ 
gle  is  meant  to  be  a  drive-cycle  global  quantity,  meaning  it  dictates 
whether  or  not  the  HVAC  is  on  for  the  entire  drive  cycle,  not  whether 
or  not  it  is  on  at  a  particular  moment  in  time.  Similar  to  the  bat¬ 
tery  chiller,  the  vehicle  air  compressor  is  modeled  as  a  constant 
load  since  air  use  is  not  quantified  by  the  model.  Finally,  the  fuel 
cell  balance-of-plant  loads  are  modeled  in  a  specific  subsystem  for 
each.  Within  the  subsystem,  the  loads  are  calculated  as  functions 
of  the  power  request.  These  functions  can  be  easily  modified  for 
experimentation  purposes. 


Fig.  8.  Transmission. 

manufacturer,  or  they  can  be  determined  with  current  or  power 
limits.  Speed  limits  are  also  typically  specified  by  the  manufacturer 
based  on  balance  tolerances  and  bearing  design.  The  losses  block 
(see  Fig.  7)  uses  a  two-dimensional  map  to  determine  the  amount 
of  power  lost  for  all  operating  points.  The  map  is  indexed  by  torque 
and  angular  velocity. 

2.1.7.  Transmission 

The  transmission  subsystem  (Fig.  8)  is  a  relatively  simple  system. 
The  two  most  important  calculations  for  a  transmission  model  are 
input/output  torques  and  losses.  This  model  takes  the  torque  from 
the  traction  motor  and  converts  it  to  a  torque  to  the  wheels.  The  cal¬ 
culation  is  done  using  a  constant  gear  ratio  and  torque  loss  vs.  speed 
map.  In  addition  to  these  calculations,  the  transmission  subsystem 
calculates  the  upstream  angular  velocity  based  on  the  downstream 
angular  velocity  from  the  wheels. 


2.1.6.  Traction  motor 

The  traction  motor  (also  known  as  the  drive  motor)  is  one  of  the 
most  important  parts  of  the  simulator  (Fig.  7).  In  this  subsystem,  all 
of  the  necessary  calculations  are  performed  to  determine  available 
drive  torque  that  eventually  results  in  vehicle  motion.  The  inputs 
to  this  subsystem  are  torque  command,  upstream  available  voltage, 
and  downstream  angular  velocity.  The  outputs  are  current  request 
and  available  torque. 

Given  an  upstream  available  voltage,  the  motor  calculates  the 
necessary  current  to  achieve  the  torque  requested  from  the  vehicle 
controller.  This  is  done  by  first  limiting  the  inputs,  and  then  cal¬ 
culating  losses.  Torque  limits  are  typically  specified  by  the  motor 


2 A. 8.  Wheels/vehicle 

The  wheels/vehicle  subsystem  (Fig.  9)  is  the  final  link  in  the  over¬ 
all  model.  This  subsystem  is  responsible  for  calculating  all  of  the 
external  forces  on  the  vehicle  including  aerodynamic  drag,  gravity 
drag  (grade),  rolling  resistance,  and  wheel  torque.  This  subsystem 
balances  all  of  these  forces  and  determines  vehicle  acceleration. 
Aerodynamic  drag  is  calculated  by  Fdrag  =  pV2C^A! 2  where  p  is  the 
density  of  air,  V  is  the  vehicle’s  velocity  through  the  air,  Cd  is  the 
drag  coefficient  of  the  vehicle,  and  A  is  the  vehicle’s  frontal  area. 

Gravity  drag,  also  known  as  grade,  is  calculated  using 
^grade  =  mg sin(tan_1  (grade))  where  m  is  the  mass  of  the  vehicle, 


Fig.  6.  Accessory  subsystem. 


Fig.  9.  Wheel/vehicle  subsystem. 
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Table  1 

Example  internal  resistance  data 


State-of-charge 

Charging  internal 
resistance  (C2) 

Discharging  internal 
resistance  (C2) 

100 

0.206 

0.053 

90 

0.110 

0.055 

80 

0.095 

0.060 

70 

0.089 

0.070 

60 

0.083 

0.091 

50 

0.078 

0.131 

40 

0.072 

0.213 

30 

0.067 

0.375 

20 

0.061 

0.700 

10 

0.056 

1.350 

0 

0.050 

2.650 

g  is  the  acceleration  of  gravity,  and  grade  is  the  current  road  grade 
(positive  if  climbing).  Finally,  rolling  resistance  is  calculated  using 
the  formula  FRR  =  mg(CRR2  V+  CRRi )  where  CRRi  is  the  first  coefficient 
of  rolling  resistance,  and  CRR2  is  the  second  coefficient  of  rolling 
resistance  (speed-dependent).  Both  of  these  values  are  typically 
provided  by  the  tire  manufacturer. 

2.2.  Input/output  system 

In  contrast  to  most  commercially  available  simulation  packages, 
LFM  has  no  user  interface  other  than  the  traditional  MATLAB  inter¬ 
face.  Loading  of  the  simulation  inputs  is  done  at  the  script  level, 
execution  of  the  simulation  is  performed  directly  through  Simulink, 
and  data  analysis  is  conducted  with  variables  on  the  workspace. 
This  design,  while  seemingly  complex  and  cumbersome,  is  actu¬ 
ally  more  powerful  than  other  designs.  First,  this  type  of  I/O  system 
lends  itself  well  to  rapid  simulation  iterations.  For  example,  the  sim¬ 
ulation  and  all  its  ancillary  functions  can  be  scripted  such  that  the 
entire  simulation  can  be  run  repeatedly  without  user  intervention 
as  part  of  an  optimization  process.  Second,  the  simulation  structure 
itself  is  designed  to  be  easily  modifiable,  and  hence,  the  I/O  sys¬ 
tem  must  allow  modifications  to  match  the  needs  of  the  simulation 
structure. 

2.2.1.  Input  spreadsheets 

All  of  the  vehicle  input  parameters  are  stored  in  spreadsheets, 
organized  by  subsystem,  in  a  human-readable  form.  For  example, 
the  data  regarding  the  internal  resistance  of  the  batteries  are  kept 
in  a  table  similar  to  that  shown  in  Table  1.  These  data  can  be  taken 
directly  from  a  manufacturer’s  data  sheet,  extrapolated  from  exper¬ 
imental  data,  or  can  be  entirely  theoretical.  Storing  these  values  in 
a  spreadsheet  table  rather  than  a  more  typical  data  storage  method 
like  a  text  file  permits  users  to  make  modifications  more  easily  and 
helps  prevent  alignment  errors. 

2.2.2.  Output 

The  default  output  from  LFM  is  simply  to  write  the  desired  quan¬ 
tities  to  the  MATLAB  workspace.  These  values  are  written  during 


Fig.  11.  Simplified  power  system  schematic. 


the  simulation,  but  are  typically  not  available  for  reading  until  the 
simulation  is  stopped.  For  analysis  of  the  output  data,  a  script  was 
written  that  calculates  numerous  important  quantities  as  shown  in 
Table  2.  These  parameters  were  used  for  the  system  validation,  as 
shown  in  the  next  section. 


3.  System  validation 

Before  any  design  studies  could  be  performed  using  the  new 
LFM  simulator,  its  output  was  compared  with  the  physical  data 
acquired  from  a  real-world  vehicle  during  test-driving.  In  the  next 
three  sections,  the  test  vehicle  and  data  acquisition  system  will  be 
described,  followed  by  qualitative  and  quantitative  validations  of 
the  simulation. 


Table  2 

Important  global  output  parameters 


Parameter 

Description 

Expression 

Total  energy  use 

Total  amount  of  energy  output  from  the  batteries  and  fuel 
cell 

rT 

Power  use(t)  dt  for  Power  Use  >  0  t  is  time,  and  T  is  drive  cycle  length  in  s 

Energy  recovered 

Total  amount  of  negative  energy  (regenerative)  from  the 
traction  motor 

pT 

Jo  Motor  power(t)  dt  for  Motor  power  <  0 

ASOC 

Change  in  state-of-charge  from  beginning  to  end  of  the 
drive  cycle 

SOCbeginning  —  SOCenc[ 

Fuel  cell  energy  output 

Gross  energy  output  of  the  fuel  cell  stack 

Jo  Fuel  cell  power(t)dt 
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3  A.  Test  vehicle 

The  vehicle  used  for  this  study  was  designed  and  constructed 
by  Ebus,  Inc.  located  in  Downey,  CA.  Fig.  10  shows  a  picture  of  the 
bus.  It  is  a  fuel  cell  electric  hybrid  bus  that  can  hold  22  seated  and 
10  standing  passengers.  The  bus  is  driven  by  a  single  three-phase 
AC  induction  motor  that  is  rated  for  130  kW  peak  and  100  kW  con¬ 
tinuous.  The  motor  is  coupled  to  the  rear  drive  wheels  through  a 
single  speed  chain  drive  and  a  differential.  The  motor  is  powered 
from  two  300  V  strings  of  Nickel-Cadmium  batteries.  Each  string 
consists  of  50  blocks,  each  containing  five  cells.  The  cells  are  rated 
for  a  nominal  charge  capacity  of  100  Ah.  The  strings  are  connected 
in  parallel  for  a  total  energy  capacity  of  60  kWh.  This  typically  gives 
the  vehicle  approximately  70  km  of  all-battery  range. 

The  fuel  cell  is  a  Ballard  Marl<9  SSL  110  cell  19.4  kW  stack.  The 
hydrogen  is  stored  in  two  composite  high-pressure  tanks  located 
on  the  roof  of  the  bus.  The  tanks  are  rated  for  350  bar  and  can 
hold  approximately  12.8  kg  of  hydrogen.  On  average,  this  amount 
of  hydrogen  yields  a  travel  range  of  about  260  km.  Table  3  summa¬ 
rizes  the  important  specifications  of  the  bus.  Fig.  11  shows  how  the 
drive  train  is  configured  as  well  as  the  fuel  cell  balance  of  plant. 

3.2.  Data  acquisition  system 

To  construct  a  test  drive  cycle,  the  vehicle  was  driven  over  rep¬ 
resentative  routes  with  constant  Global  Positioning  System  (GPS) 
tracking.  The  GPS  periodically  collects  time,  speed,  altitude,  and 
position  information  that  can  be  used  to  construct  a  drive  cycle.  The 
GPS  used  for  this  study  was  a  Garmin  17HVS  marine  OEM  tracker. 
This  GPS  uses  the  Wide  Area  Augmentation  System  (WAAS)  which 
allows  for  an  accuracy  of  almost  1  lateral  meter.  The  GPS  outputs 


x104  Traction  Power 


Time  (s) 


3500  3600  3700  3800  3900  4000  4100  4200  4300  4400  4500  4600  4700 

Time  (s) 


Table  3 

Important  vehicle  statistics 


Parameter 

Value 

Length 

6.7  m 

Width 

2.3  m 

Gross  weight 

9300  kg 

Curb  weight 

7030  kg 

Maximum  speed 

72  km/h 

Traction  motor 

130  kW  AC  induction 

Transmission 

1 -Speed  chain  drive 

Batteries 

300  V  200  Ah  Nominal  NiCd 

Fuel  cell 

Ballard  Mark9  SSL  19.4  kW 

Hydrogen  storage 

12.8  kg  at  350  bar 

Range 

260  km 

Fuel  economy 

21.4  1/100  km  (gasoline  equivalent) 

all  of  the  relevant  data  through  an  RS-232  connection  in  NMEA 
0183  (National  Marine  Electronics  Association)  standard  format  to 
a  data-logging  computer. 

For  vehicle  specific  data,  an  interface  was  constructed  for  data 
transfer  from  the  on-board  vehicle  computer  to  the  data-logging 
computer.  These  data  include  quantities  such  as  battery  state- 
of-charge,  battery  current,  motor  power,  fuel  cell  power,  and 
configuration  parameters.  Many  of  these  quantities  are  used  in  the 
simulator  validation  process.  Table  4  shows  all  of  the  relevant  data 
that  are  collected  from  the  vehicle. 

3.3.  Vehicle  to  simulator  comparison 

The  validation  process  presented  here  is  similar  to  that  pre¬ 
sented  by  Syed  et  al.  [11].  The  plots  shown  in  Figs.  12  and  13 
demonstrate  the  validity  of  the  LFM  simulator.  Each  figure  shows 


x104  Battery  Power 


Time  (s) 


Fuel  Cell  Power  Request 
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Fig.  12.  Drive  Cycle  1— comparison  plots. 
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Fig.  13.  Drive  Cycle  2— comparison  plots. 


simultaneous  plots  of  important  quantities  for  both  the  simula¬ 
tion  and  physical  data  acquired  from  the  vehicle  during  the  same 
drive  cycle.  Using  the  speed  vs.  time  data  from  the  GPS,  an  LFM 
input  drive  cycle  was  generated  and  the  simulation  was  executed 
using  the  same  initial  conditions.  These  initial  conditions  include: 
state-of-charge,  average  power  requirement,  and  accessory  loads. 
The  output  of  the  simulation  was  used  to  generate  the  comparison 
plots  shown  in  Figs.  12  and  13,  each  for  a  different  test  drive  cycle 
(“Drive  Cycle  1”  and  “Drive  Cycle  2”,  respectively). 

Fig.  12  compares  traction  power  (motor  electric  power  usage), 
battery  power,  battery  state-of-charge,  and  fuel  cell  power  request. 
Notice  that  fuel  cell  power  request  is  used  and  not  fuel  cell  power. 
This  is  because  for  both  the  real  vehicle  and  the  simulation,  the 
actual  fuel  cell  power  output  becomes  saturated  at  the  maximum 
power  output.  Therefore,  it  is  of  greater  interest  to  plot  power 
request  from  the  hybrid  control  algorithm,  rather  than  actual  power 


Table  4 

Vehicle  data  acquisition  parameters 


Vehicle 

Fuel  cell  system 

GPS  tracking 

Battery  SOC 

Air  flow  rate 

Latitude 

Battery  current 

Air  temperature 

Longitude 

Battery  voltage 

Air  humidity 

Ground  speed 

Battery  temperature 

Air  pressure 

MSL  altitude 

Traction  current 

Coolant  flow  rate 

Bearing 

Traction  power 

Coolant  temperature 

Position  error 

Motor  temperature 

Motor  speed 

Coolant  pressure 

Hydrogen  flow  rate 

Hydrogen  temperature 
Hydrogen  humidity 
Hydrogen  pressure 

Stack  voltage 

Time  of  day 

output.  The  purpose  of  Fig.  12  is  to  illustrate  the  degree  of  alignment 
between  the  simulator  prediction  and  actual  vehicle  performance. 

Fig.  13  shows  the  same  comparison  as  in  Fig.  12  except,  instead  of 
fuel  cell  power  request,  battery  voltage  is  plotted.  During  this  par¬ 
ticular  test  drive  cycle,  the  battery  state-of-charge  never  dropped 
below  the  threshold  value  to  activate  the  fuel  cell  system.  Therefore, 
fuel  cell  power  request  was  always  zero. 

To  reinforce  the  confidence  in  the  simulation  outputs,  Table  5 
shows  a  comparison  between  the  vehicle  and  simulator  for  several 
global  drive  cycle  quantities.  This  comparison  is  more  quantitative 
than  the  plots  shown  in  Figs.  12  and  13,  and  helps  to  demonstrate 
the  robustness  of  the  simulation  by  calculating  these  quantities  for 
several  different  drive  cycles. 

The  majority  of  the  error  values  shown  in  Table  5  are  below 
15%.  Flowever,  a  few  error  values,  typically  associated  with  state-of- 
charge  change,  are  higher.  For  example,  the  error  of  state-of-charge 
change  for  Drive  Cycle  5  is  22.6%.  This  percentage  error  is  high 
because  the  error  is  normalized  by  the  actual  values  for  state-of- 
charge  change  which  are  usually  low  for  both  the  actual  vehicle  and 
the  simulation  prediction.  The  other  high  error  values  are  the  result 
of  several  factors  including  inaccuracies  in  data  acquisition  and  lack 
of  well-quantified  data  for  various  subsystems  on  the  real  vehicle 
(for  example,  battery  internal  resistance).  In  general,  a  tool  such  as 
this  will  be  used  more  to  design  a  new  vehicle  powertrain  rather 
than  improve  upon  an  existing  design.  In  this  respect,  the  acquisi¬ 
tion  of  more  accurate  modeling  parameters  can  vastly  reduce  these 
errors. 

It  is  of  interest  to  determine  the  source  of  the  errors  presented  in 
Table  5.  The  source  of  error  for  total  energy  use  is  the  most  difficult 
to  determine  precisely  since  total  energy  used  depends  on  sev¬ 
eral  downstream  calculations.  A  logical  approach  is  to  examine  the 


Table  5 

Quantitative  comparison 
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Parameter 

Drive  Cycle  1  (8,700  s) 

Drive  Cycle  2  (11,330  s) 

Vehicle 

Simulation 

Error  (%) 

Vehicle 

Simulation 

Error  (%) 

Energy  use  (Wh) 

38,293 

37,561 

1.9 

52,466 

49,617 

5.4 

Energy  recovered  (Wh) 

6,619 

6,551 

1.0 

8,110 

8,463 

4.4 

State-of-charge  change  (%) 

-29.2 

-30.7 

5.2 

-30.4 

-35.0 

15.2 

Fuel  cell  energy  output  (Wh) 

13,137 

12,632 

3.8 

22,417 

21,048 

6.1 

Parameter 

Drive  Cycle  3  (11,190  s) 

Drive  Cycle  4  (13,342  s) 

Vehicle 

Simulation 

Error  (%) 

Vehicle 

Simulation 

Error  (%) 

Energy  use  (Wh) 

49,936 

49,664 

0.5 

53,565 

58,439 

9.1 

Energy  recovered  (Wh) 

7,444 

6,700 

9.9 

8,834 

7,657 

13.3 

State-of-charge  change  (%) 

-31.8 

-37.2 

17.0 

-38.0 

-43.4 

14.3 

Fuel  cell  energy  output  (Wh) 

19,092 

20,473 

7.2 

18,749 

21,543 

14.9 

Parameter 

Drive  Cycle  5  (6,000  s) 

Drive  Cycle  6  (9,340  s) 

Vehicle 

Simulation 

Error  (%) 

Vehicle 

Simulation 

Error  (%) 

Energy  use  (Wh) 

33,403 

29,570 

11.4 

51,715 

47,120 

8.8 

Energy  recovered  (Wh) 

4,928 

5,243 

6.4 

6,854 

6,838 

0.2 

State-of-charge  change  (%) 

-5.3 

-6.5 

22.6 

-10.0 

-11.5 

15.0 

Fuel  cell  energy  output  (Wh) 

20,118 

18,979 

5.6 

30,440 

30,142 

0.9 

error  contributions  from  each  of  these  downstream  systems.  One 
important  contributor  would  be  energy  recovered,  which  is  a  direct 
function  of  the  motor  power  calculation.  Error  from  this  subsys¬ 
tem  is  most  likely  caused  by  inaccurate  motor  efficiency  modeling. 
Again,  more  reliable  and  accurate  performance  data  would  improve 
this  situation.  The  error  in  state-of-charge  change  is  most  likely 
incurred  during  vehicle  SOC  calculation  since  SOC  is  calculated  by 
simply  integrating  the  battery  current.  Consequently,  the  error  in 
fuel  cell  energy  output  is  caused  by  the  error  in  SOC  calculation 
because  the  fuel  cell  power  request  is  a  function  of  battery  SOC. 

4.  Summary 

A  vehicle  powertrain  simulator  called  LFM  was  developed  to 
incorporate  a  flexible  and  easily  modifiable  structure  such  that 
changes  to  the  fundamental  vehicle  design  could  be  rapidly  imple¬ 
mented  without  compromising  model  accuracy  or  simulation 
computational  performance.  The  MATLAB/Simulink  environment 
was  used  to  define  and  link  various  subsystems  of  the  hybrid  vehi¬ 
cle  powertrain.  A  system  validation  study  conducted  by  comparing 
time-dependent  data  from  the  simulation  with  physical  data  taken 
from  a  fuel  cell  hybrid  transit  bus  demonstrates  that  the  simula¬ 
tor  is  able  to  reliably  predict  the  vehicle  performance.  Additional 
comparisons  of  global  quantities  computed  from  the  overall  drive 
cycle  show  that  the  LFM  simulator  yields  reliable  and  robust  perfor¬ 


mance  results  and  should  prove  useful  as  a  design  tool  for  various 
hybrid  platforms. 
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